The history of Service Oriented Architecture is very difficult to trace because of the term ``Service Oriented Architecture'' has been defined by several people and it is hard to determine who actually coined the term and for what meaning. To drive this point home, here are some definitions of ``Service Oriented Architecture'' that can found on the Internet and literatures:
\begin{itemize}
\item {\bf Wikipedia definition of SOA  (July 17, 2006):} In computing, the term Service-Oriented Architecture (SOA) expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In an SOA environment, resources on a network are made available as independent services that can be accessed without knowledge of their underlying platform implementation \cite{Nicolai}.
\item{\bf OASIS reference model definition of SOA:} Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains \cite{Nicolai}.
\item{\bf Thomas Erl's definition of SOA:} Contemporary SOA represents an open, extensible, federated, composable architecture that promotes service-orientation and is comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, and potentially reusable services, implemented as Web services. SOA can establish an abstraction of business logic and technology, resulting in a loose coupling between these domains. SOA is an evolution of past platforms, preserving successful characteristics of traditional architectures, and bringing with it distinct principles that foster service-orientation in support of a service-oriented enterprise. SOA is ideally standardized throughout an enterprise, but achieving this state requires a planned transition and the support of a still evolving technology set \cite{Nicolai}. 
\end {itemize}
The definitions address parts of SOA such as platform independence, an architecture with interoperability and distributed systems. However, most of these definitions do not define SOA in its entirety and it is not clear what SOA is in simple terms. It is still not clear whether or not SOA is a product one can buy or some paradigm that one must master.
 
Although very much disputed, the term ``Service Oriented Architecture'' is believed to be coined by a Gartner analyst named Alexander Pasik who used the term SOA for a class he was teaching in middleware in 1994. Then the first paper on SOA, ``Service Oriented Archtecture part 1'' was published and was written by Gartner analysts Roy W. Schulte and Yefim V. Natis in 1996. \cite{Nicolai}

Before Web Services were introduced, SOA was a basic model that consisted of three basic components: the service requestor, the service provider, and the service registry. Figure 1 shows an early model of SOA.

\begin{figure}
\begin{center}
\includegraphics[angle= 270, width=0.5\paperwidth]{fig1.eps}
\caption{Early incarnation of SOA. \protect\cite{qusay}} 
\par\end{center}
\end{figure}

This early incarnation of SOA shows that SOA was viewed as a ``find-bind-execute'' paradigm where service providers register their services in a public registry. This registry is used by customers to find services that meet their needs and if the regstry has such a service, it provides the customer with a contract and an endpoint address for that service \cite{qusay}.

\subsection{The Rise of Service Oriented Architecture}

Service Oriented Architecture gained its popularity from the fact that it dealt with the increasing complexity of certain software systems. At the time, software became increasingly more and more complex. Many companies developed complex distributed systems that were hard to develop, maintain, and debug. Distributed systems, which were comprised of components or nodes in a network that communicate with each other, consisted of components and/or resources that were not all the same. Components differed in their operating systems and by their programming languages. In addition, each node in the network is controlled by a different owner and so one cannot control changes made and cannot have the system work in one specific way. Distrbuted systems also lacked harmony which made the system heterogeneous. They can employ a mess of mainframes, SAP hosts, databases, J2EE applications, and even small rule engines that makes the entire system heterogeneous \cite{Nicolai}.

Many have tried in the past to solve the problem of integrating distributed systems by eliminating heterogeneity. By having all systems use the same platform, the same programming language, or the same types of applications, then the system would be in a sense homogeneous in terms of technology. These approaches to ``harmonize'' distributed systems did not work in the long run because large distributed systems will eventually be controlled by different owners who would use different applications/implementations for their respective systems \cite{Nicolai}. 

Service Oriented Architecture addresses these issues of increasing complex systems by accepting the fact that complex distributed systems are inherently heterogeneous. SOA acknowledges and accepts this attribute of distributed systems. Similar to agile development accepting the fact that requirements frequently change during software development, SOA accepts the fact that distributed systems will always be constructed by different applications and platforms. This essential idea in SOA is what gave SOA its popularity. SOA aims to deal with the acceptance of heterogeneity and does not care whether or not heterogeneity is good or bad. Such a concept makes Service Oriented Architecture powerful in the sense that no matter what different technologies or platforms one uses in a system, SOA is completely independent of it and tries to interoperate those different technologies \cite{Nicolai}.

\subsection{Service Oriented Architecture from 2000-present}

As more and more people understood and implemented Service Oriented Architecture, SOA began to be loosely defined as having the following three concepts around the 2000s: services, loose coupling, and interoperability \cite{Nicolai} as oppose to the early 1990s component structure shown in figure 1. A service is an IT representation of some business functionality. Loosing coupling, as defined previously, minimizes dependencies such that the system still runs when parts of it are still broken or simply down temporarily. Interoperability refers to the goal of connecting different systems easily. These concepts enforce Service Oriented Architecture to be a powerful paradigm that help businesses aim to improve flexibility in their complex systems. Having flexibility in systems can make maintenance and development much easier to do \cite{Nicolai}.

Serviced Oriented Architecture gained real momentum when Web Services were introduced. Web Services, which was a term coined by Microsoft in the year 2000, was loosely defined as a set of standards that allow computers to communicate with each other through a network. After web services was introduced, standards were created such as XML, HTTP, WSDL, and UDDL for communications over the network \cite{Nicolai}. 

Web Services inherently have to deal with interoperable machine to machine interaction over a network, much like Service Oriented Architecture. One then can realize SOA with Web Services. Businesses can use web services to implement Service Oriented Architecture to create novel, state of the art applications. Figure 2 shows an example of how Web services can employ a Service Oriented Architecture:

\begin{figure}
\begin{center}
\includegraphics[angle= 270, width=0.5\paperwidth]{fig2.eps}
\caption{Web Services representation of SOA. \protect\cite{qusay}}
\par\end{center}
\end{figure}

Even today, where Service Oriented Architecture is becoming more and more popular, it still has many definitions. However, many of these definitions share the same basic ideas. Today, SOA can be defined as having three essential characteristics: services, an enterprise service bus, and loose coupling. 

The service, which is a piece of of self contained business functionality, might be as simple as storing or retrieving customer's data, or complex such as a business process for a customer's order. But the most important aspect of a service is the interface which serves as a bridge between the business end of the service and the software/IT end of the service. The Enterpise Service Bus is the infrastructure that enables high interoperability between distributed systems for services. It makes it easier to distribute business processes over multiple systems using different platforms and technologies. Loose coupling helps to reduce system dependencies such that effects of modifications and failures are minimized \cite{Nicolai}. 
